Category Archives: Win

Mac users rejoice – at long last, a LISP IDE comes to OS X

What’s happened?

With the release of BricsCAD (Mac) V18.2 (currently V18.2.23-1 to be precise), BLADE (BricsCAD’s much-superior equivalent to VLIDE) has been added to BricsCAD

See here for the release notes and here to download. Make sure you select the Mac version:

Significance

This is pretty significant for anybody serious about using DWG-based CAD on the Mac. AutoCAD without LISP is hardly worthy of the name, which is why I’ve never been keen on AutoCAD LT from the moment LISP was yanked out of it just before release in the early 90s. There has never been an integrated development environment for AutoCAD for Mac (either in the first iteration in the 1990s or the second attempt in the 2010s) and I think I can safely predict that there’s never going to be one. I expect AutoCAD for Mac’s LISP to remain forever in 1990 mode.

Compatibility

One problem a small number of users may face when developing for Mac with BLADE is that of downward compatibility. In case you’re wondering, BricsCAD (Mac) to AutoCAD for Mac is very much a downward direction, particularly in the area of LISP. The LISP in AutoCAD for Mac is famously half-baked with large portions of functionality missing, including no ability to control dialog boxes. BricsCAD (Mac)’s LISP is very much more capable, so while compatibility between AutoCAD for Windows and BricsCAD (Mac) is strong, you can’t say the same for LISP compatibility between AutoCAD for Windows and AutoCAD for Mac.

Half of the stuff you write for AutoCAD in Windows is just going to fail when you try to run it in AutoCAD for Mac. Much more of it is going to work in BricsCAD (Mac). While you can now write, debug and run your LISP code efficiently in BricsCAD (Mac) and it’s practically guaranteed to run just fine in AutoCAD and BricsCAD for Windows, it will be very easy to write stuff in BricsCAD (Mac) that doesn’t work in AutoCAD for Mac. Of course, the same downward compatibility problem applies to writing stuff in AutoCAD for Windows using VLIDE.

If you’ve moved on completely from AutoCAD for Mac to BricsCAD (Mac), that’s not going to be a problem. Bircsys building a notably better product that’s significantly more compatible with the main game is not something anybody could reasonably condemn. However, but it’s something to bear in mind if you are hoping to write code that runs on both AutoCAD and BricsCAD for Mac.

Summary

That caveat aside, it’s all good news for Mac CAD users. You already had a product available that would run a much higher percentage of the huge library of LISP out there than AutoCAD for Mac would. For the first time in history, you now also have access to a professional LISP development tool. Lucky for you, it’s the best such tool on the market.

Importing SketchUp files into AutoCAD

2 Replies

Do you have a SketchUp (SKP) file you need to import into a DWG? Need to know how to do it? Tried it but it didn’t work? This tip is for you.

If you’re using AutoCAD 2016 to 2019 for Windows, you can download and install the SketchUp Import plug-in from the Autodesk App Store. If that goes according to plan, this will add the command IMPORTSKP to AutoCAD. You may need to restart your AutoCAD first. It’s straightforward enough; select a file to import and it becomes a block in your drawing.

Reading the reviews for this add-on, it’s clear that it’s not working for many people. If it does work, it only imports SketchUp files up to 2017 format (2016 on 32-bit AutoCAD).

What if it doesn’t work? What if it does work but you have an unsupported 2018 version SKP file? Well, this post could arguably fit into the Why every AutoCAD CAD Manager should have a copy of BricsCAD series, because this is an example of BricsCAD acting as a workaround for AutoCAD limitations. SketchUp files are supported in BricsCAD’s native Import command, no add-ins required. If you have BricsCAD V18.2.10 or later, 2018 version SKP files are supported. If you have an earlier version of BricsCAD you can download the latest here.

Importing SKP files is also supported in the free BricsCAD Shape application, but at the time of writing the version is V18.2.06, which only supports SKP files up to 2017 format.

The game has changed – Robert Green migrates to BricsCAD

10 Replies

Is anybody left who still thinks BricsCAD isn’t a serious replacement for AutoCAD? If that’s you, perhaps the latest news might make you take it seriously. No, not the Heidi Hewett news. Even more recent news than that!

Robert Green, CAD Management guru, Cadalyst writer and consultant (not to mention a rather good guitarist) has been announced as the first Bricsys Certified Migration Consultant.

Image courtesy of Bricsys

Read all about what Robert has to say on this Bricsys blog post.

Anybody who has been reading this blog for the last few years will be surprised by none of what Robert has to say in that blog post. It’s not merely a repeat of what I’ve been saying for some time now, it’s all factually correct and easily verifiable by any competent CAD Manager.

I’ve been there and done that. I’ve gone through the process of taking a very complex custom AutoCAD environment, applying it to BricsCAD and giving it to my users. They loved it. No training was required to work as usual. Most things happened quicker, more conveniently, or both, starting right from the speedy installation. Once the product is in place and established, training can then be applied to take advantage of the places where BricsCAD is ahead of AutoCAD.

If you’re a CAD Manager where AutoCAD is used and you haven’t checked out BricsCAD yet, it’s about time you did.

This might come as a shock to those who see Autodesk domination of DWG CAD as a permanent fact of life, but the game has changed. AutoCAD’s stagnation and comments by senior figures show that the former flagship is clearly unloved by the powers within Autodesk. AutoCAD LT, even more so. An unimpressive AutoCAD 2019 shows that major improvements can no longer be expected in exchange for your ever-increasing annual payments, and with large numbers of people having been offloaded from the research and development teams, who would do it anyway? Meanwhile, BricsCAD development shoots ahead.

Thanks to decades of hostility towards customers that has only accelerated in recent years, Autodesk can’t even rely on customer loyalty for survival. When there’s a serious competitor that offers an easy migration path, the inertia that has kept Autodesk alive so far in the DWG space is no longer enough. The feeling among industry observers I meet is that Autodesk is in a decline of its own making. The only debate is whether that decline is temporary or terminal.

Back to Robert et al. Autodesk has lost many good people, and Bricsys is gaining them. The momentum is clearly with the Belgian company. Anybody want to run bets on who the next big name defector will be?

Heidi Hewett – Autodesk loses, Bricsys gains

2 Replies

The most excellent Heidi Hewett was, bafflingly, one of the big-name casualties in Autodesk’s latest experience cull. What was already a big loss to Autodesk has been compounded by her arrival at Autodesk’s most significant AutoCAD competitor, Bricsys.

Heidi has accepted a position as User Success Manager with the Belgian company. I don’t blame her. Bricsys is where the action is. Here’s her opening salvo:

For well over a decade, the world was told that the .dwg file format is not suitable for advanced design workflows. It can’t be used for mechanical design, and it certainly can’t be used for BIM. Bricsys has shown that this old belief is simply not true. The .dwg file format is alive and well and kicking serious butt. I am looking forward to helping Bricsys take .dwg to new, previously unimagined levels, and I’m excited to be part of the team that is doing this for our users.

Is it just me, or does Heidi look more relaxed in her Bricsys photo than she ever did in her Autodesk ones?

Photo credit: Bricsys

Here’s Heidi’s first Bricsys blog post. Can you feel her genuine excitement? Maybe she’s just happy that she’s going to have masses of real improvements to write about, rather than having to stretch out an ever-shrinking set of new AutoCAD features each year.

Given Heidi’s outstanding contribution to assisting CAD users over many years, I’m very happy that she is now going to be able to continue that work. I suspect she’s going to be very busy!

Autodesk loses, Bricsys gains. Big time. What on earth was Autodesk thinking?

How to get your Wacom Graphire 4 tablet working in Windows 10

67 Replies

I’ve been setting up a new PC at home and one of the things I struggled with was getting my Wacom Graphire 4 tablet working. This isn’t a CAD tablet (remember those?); instead, I use its pressure-sensitive stylus for image creation and editing. Press harder and you get more ink. Turn the pen over and you automatically erase instead of drawing. Press the eraser harder and you get more erasing.

I use PaintShop Pro for my image work, by the way, not Photoshop. You can still buy and optionally upgrade PaintShop Pro perpetual licenses, which is how it should be. You’re probably aware that I don’t rent stuff unless there’s no realistic alternative.

According to the Wacom FAQ, I was severely out of luck.

What is the latest driver for the Graphire 3 & 4 (CTE) tablets?
The Graphire 3 & 4 CTE tablets made from 2003-2007 are no longer supported by Wacom and will not work with a current tablet driver. Below are links to the latest drivers available for these tablets.

Windows 8, Windows 7, Vista & XP Download Here
Mac 10.8, 10.7 & 10.6 Download Here

Not one to give up so easily, I tried a variety of drivers for my tablet (model CTE-440). They were either blocked from installation by Windows 10×64, or in the best case scenario failed to provide any functionality other than acting as a basic mouse. The tablet failed to appear as a WinTab device, so I couldn’t configure PaintShop Pro to use its pressure-sensitivity, defeating the object of having the thing in the first place.

So I did what I thought was best and put the tablet out on the verge with the other junk awaiting council collection and investigated a replacement. Not from Wacom, obviously! I don’t want to reward a company for abandoning its products. I was checking out Huion tablets, which are so much cheaper than Wacom’s that it’s probably worth taking a punt and buying one anyway.

But then the stubborn streak in me (have you noticed?) kicked back in and I had one last go. A bit more in-depth Googling led me to this page. This is an old, non-maintained, leftover page from Wacom Europe. Let’s hope it stays there. On that page I found the driver I needed: DRIVER 5.30-3 RC FOR WINDOWS 8, WINDOWS 7, VISTA, AND XP. The direct link to the driver installation executable (cons530-3_int.exe) is:

http://downloadeu.wacom.com/pub/WINDOWS/cons530-3_int.exe

I retrieved my tablet from the junk pile, installed that driver, cleaned off my tablet while my system rebooted, plugged it in and away I went! In PaintShop Pro 2018, the setting is found at File > Preferences > General Program Preferences in the Miscellaneous section.

Wacom’s FAQ gave me a bum steer. Yes, the driver I used isn’t supported in Windows 10 and it isn’t current, but I don’t care. It works just fine and means my perfectly good as-new tablet isn’t landfill. Wacom needs to do better both in terms of supporting its hardware with current drivers and providing more useful information to its customers.

Rock on, Robert Green!

1 Reply

I’d like to offer my congratulations to Robert Green on his landmark of 400 issues of the CAD Manager’s Newsletter. There’s a interview with Robert here.

As a fellow CAD Manager and Cadalyst contributor, I’ve admired Robert’s work for many years. I finally got to meet Robert last year at the Bricsys Conference 2017 in Paris, and it was a pleasure.

Legends on stage – Robert being interviewed by Don Strimbu at Bricsys 2017

Robert, R.K. McSwain and Steve enjoy lunch at the Carrousel du Louvre

No pictures! R.K. McSwain, Nancy Johnson and Robert

Robert rocks out

Some of you will already be aware that Robert is a seriously good guitarist, and he did not disappoint at the after-conference party. I look forward to seeing Robert again, and to reading many more of his insightful articles.

BLADE – putting things back to “normal”

2 Replies

Disclaimer: I’m making money using BLADE. I’m using it on a paying project right now (well, not while I’m typing this, but you get the idea). I’m developing a routine to automate a massively repetitive task for one of my AutoCAD-using clients, and I’m developing it in BricsCAD and BLADE rather than AutoCAD and VLIDE.

I can simply develop faster in the more modern environment, and BricsCAD’s significantly quicker start-up time helps with that. So does the fact that the routine runs several times faster in BricsCAD, making testing the large data sets much more efficient. I’m getting paid on results and not by the hour, so using BLADE is putting cash straight into my pocket while giving me more time to walk my dog.

Using BLADE in production, I’m discovering a few bugs, quirks and things I don’t like. That’s totally understandable with a new feature of this level of complexity and functionality. Where I think it makes sense, I’m submitting problem reports or feature requests to Bricsys. I’m sure Bricsys already has a bunch of these from other developers, so they’ll be very busy for a while. From past experience, I know my reports will be taken seriously and acted on appropriately in a timely manner, if it’s feasible to do so. Your LISP IDE feedback won’t be ignored for decades by Bricsys.

One of the things Torsten Moses mentioned to me that didn’t make it into the published interview was that many developers are very conservative. There’s some truth in that. I’m missing certain keystrokes, for example: 1978-era WordStar Ctrl-Y to delete a line, anyone? It’s a reasonable expectation that as more VLIDE users migrate to BLADE, many requests will come in for VLIDE-like things. I’m told that some of these things will be provided in coming months.

In the meantime, there are things we conservative developers can do to make ourselves feel more at home. One of these is to configure the editor appearance. Here’s the VLIDE editor:

Here’s the BLADE equivalent:

One of the great things about BLADE is how configurable it is, and I know Torsten’s working right now on making it even more so. Configurations are stored in the Registry in a version-independent location (HKCU\Software\Bricsys\BricsCAD\VLispDbgEditor). These can be exported and imported directly or via BLADE, so multiple complete setups and configurations can be managed.

In this post, I’m going to be going through the process of configuring BLADE’s editor appearance to make it look more like VLIDE. I’m not suggesting that’s necessary or even a good idea in most cases, but if you really want to do it, here’s how.

Note: before you do all this manually, please note that at the end of this post I will provide a configuration file that will do it for you.

Start up BricsCAD V18.2 or later and start BLADE using either the BLADE or VLIDE command.
Open a LISP file in BLADE so you can check the effects of the changes we’re going to make.
Use Preferences > Show preference dialog…
In the Preferences & Settings dialog, pick the Styles tab and the Lexer Styles sub-tab.
I’m perfectly happy with Courier New 10, but if you want the VLIDE look, change 1 – Default text to Fixedsys 11.
Click next to 3 – Comment, turn on the Background color toggle and change the Back Color to mid-grey (192,192,192) and Fore Color to dark magenta (128,0,128). You’ll need to specify that RGB value in the lower right corner and use Add to Custom Colors to do this.
Click next to 5 – String and change the Fore Color to magenta (255,0,255).
Click next to 7 – Operator and change the Fore Color to red (255,0,0).
The 8 – Keyword 1 setting should already be blue as in VLIDE. If you want system constants such as T, nil and pi to also be that shade of blue then change 9 – Keyword 2 accordingly. Personally, I prefer a different shade so they stand out. Mid-dark cyan (0,128,192) works well.
I like the pale grey background in BLADE that helps identify the current line. If you don’t, click next to 8 – Caret colour and turn off the Background color toggle.
Switch to the Editor Colors sub-tab, click next to 5 – Selection colour and change the Back Color to a custom mid-blue (0,120,215).
While you’re in the Editor Colors sub-tab, there are a few other non-VLIDE things you can play with. 1 – Brace hilight and 2 – Brace mismatch are dynamically applied to matching and non-matching parentheses respectively. I like my Brace hilight setting to be plum and bold (turn on the Attributes toggle to enable this):

I like my non-matching setting to be white on red (the inverse of a normal parenthesis so it shows up):

Changing all that should give you something that looks like this. Familiar enough?
There are several things in the above image that might be unfamiliar but which I suggest you leave turned on because they’re useful. If you really insist, here are the locations for these settings in the Preferences & Settings dialog:

Line numbers – View > Margins, Show line number margin
Marker margin – View > Margins, Show marker margin. If this is turned off, bookmarks show up using the settings under Styles > Editor Colors > 13 – Bookmark marker.
Edge marker (that vertical line on the right indicating 80 character width) – View > Edge marker > Type, No background.
Indentation guides (those vertical lines that show you what your code is lining up with) – Tabs and EOL > Indentation, Show indentation guides.
Code folding margin (the margin on the left that allows you to collapse functions, etc. – Folding and Wrapping > Show code folding margin.

Unlike VLIDE, the default in BLADE is to use spaces for indentation, not tabs. As I don’t know of any LISP developer who uses tabs except by accident, this is a much more sensible default. But if you really want to use tabs, turn it on using Preferences > Use tabs and set the width to the VLIDE default of 8 in Preferences > Set tab width.

If you’ve left opening parentheses on previous lines and have indented the following code as usual, then as you go on to finish off the code with closing parentheses, in BLADE a single backspace will take you back your indent width (2 spaces by default) rather than a single space as in VLIDE. If your coding finger can’t get used to this keystroke-saving feature, you can turn this off with Preferences > Backspace unindents.

Having done all that, and having arranged the rest of the interface to your needs (overall window size, pane and field widths, etc.), make sure you save it! It’s as simple as Preferences > Save preferences, but it’s not done automatically. If you want to keep a safe copy of your settings, you can do so with Preferences > Save preferences to file. This simply exports the relevant part of the registry to a .reg file of your choice. This is a text file you can hack about with at your leisure (using BLADE if you like!), and you can even make files that represent subsets of your preferences.

For example, I’ve removed all but the style settings from a .reg file I exported. I’ve uploaded it renamed as a .txt file because .reg files are considered dangerous by browsers, etc.

If you want to use this to give BLADE that old familiar VLIDE look, here are the steps.

Download SteveVLIDE-likeBLADEStyleSettings.reg.txt.
Rename the file to remove the .txt extension so it becomes SteveVLIDE-likeBLADEStyleSettings.reg.
In BLADE, use Preferences > Load Config from File
Close BLADE and BricsCAD.
Restart BricsCAD and BLADE.

That should do it. Happy BLADEwork!

Interviewing the creator of BLADE – CAD’s best LISP IDE – part 2

2 Replies

This post continues my interview with Torsten Moses about BLADE, the new LISP IDE that arrived with BricsCAD V18.2. See here for post 1.

Steve: I’ve noted before that BricsCAD execution of AutoLISP and Visual LISP is several times faster than AutoCAD’s. How does the new technology affect that performance?

Torsten: All the new BLADE-related stuff doesn’t really affect normal LISP execution outside the IDE and debugger. The connection is made by a few callbacks, which take zero time in normal processing. Therefore there is also no chance of breaking things. The BLADE implementation is very safe, and performance remains high for normal usage. For the debugger and the synchronization, it is all home-brewed stuff, optimized for best performance even when debugging, and minimum system and LISP memory usage.

In the course of implementing the debugger and internal versus external synchronization, I also removed most emulations and implemented that as core OpenLisp functionality. That has the side-effect that the (repeat), (foreach) and (vlax-for) functions now run about five times faster at the loop construction. So rather than slowing things down, creating BLADE has actually speeded things up!

Steve: Will the Mac and Linux versions also get this feature?

Torsten: Yes, it is fully compatible. This is due to the implementations of WxWidgets and my own stuff. I have already verified BLADE running under Linux. There are no differences; even the implementation code has no Windows-specific stuff.

Steve: Can you give a simple example of the workflow of a debugging session?

Torsten: First, don’t pre-load any LISP file into BricsCAD. Such code loaded outside the debugger is fully functional, but it can’t be used for debugging. The special connection between internal and external representation is only established when loading the LISP code under a debug state.

Next, in BLADE open an existing FAS or VLX project, and/or a “Named Session”, or simply any LISP file you want to start debugging with.

Now you can select Start Debugging from menu or toolbar, or hit the F8 hotkey. The special Debug Toolbar will appear. You can either activate AutoBreak, which stops at first executable code, or activate the LISP source where you want to start debugging and place some breakpoints.

Then load the dedicated LISP file, either by the normal Load into BricsCAD function, or from the Load button in the Debug Toolbar. Now that loaded code is debug-enabled and you will see the file and debug-enabled functions in the two right tabs.

When the debugger halts at the first breakpoint, all debug-step modes are enabled in the toolbar, and you have all the usual debug step modes. More than in AutoCAD’s VLIDE, actually. You can set the watches (observed and tracked variables) as “Data Break Point” by activating the checkbox. Then, whenever that value changes, the debugger also stops automatically at the related LISP statement.

Steve: What if your code calls code in other files you haven’t loaded?

Torsten: Don’t worry about that. The debugger recognizes this and will ask to load the related LISP file on-demand. In normal LISP, you would get an unknown function error but the debugger catches this upfront. In fact, this is one of the high-end features – only load the primary LISP file, any further debugging into other files resolves by loading during the debugging session. This is very handy for dealing with complex apps – there’s no need to preload any other LISP source. I’m sure you’ve experienced Murphy’s Law, where the particular function you need is the one that’s not loaded. You won’t have that problem in BLADE.

Steve: Where to from here? Is this job done or is there still room for improvement?

Torsten: As BLADE is still a very young product, there is definitely a lot more to come. So far, the main target was to provide good debugging features, and a somewhat reasonable handling of projects, but not so much focusing on plain editor capabilities.

My to-do list still has a number of major key features to be implemented. We want to add a hotkey editor, because every developer loves his own keystrokes and learning others is a nightmare! We also want cross-reference checking on a per-file and per-session basis, mainly for bigger LISP applications.

Then, over time, the editor capabilities will be extended and improved, providing more features. One example is to provide an editor tooltip that shows a function signature and short help when hovering over a LISP function name.

And of course, I’m aware that when people start using this in production, a lot of feedback will arrive from developers in the form of wishes, hints for improvements and bug reports. It’s very likely there will be many wishes to implement several details to make BLADE resemble AutoCAD’s VLIDE more closely. This could be a bit difficult sometimes, and is also not the main target. I hope that developers will be open to a slightly different workflow, given the big advantages they get in return.

In general we are very open to developer ideas, needs and requirements, as we are with BricsCAD itself. In the end, it’s the developer who needs to work with BLADE, as easily and productively as possible. Even the initial release of BLADE is based on important feedback from beta testers such as Martin Drese (CAD Wiesel).

Steve: I can certainly attest to how well you respond to feedback. I’ve seen bugs I’ve reported fixed in a very short timeframe.

Torsten, thank you for your time. This has been very illuminating.

This interview is also available in one post on the Bricsys blog.

Interviewing the creator of BLADE – CAD’s best LISP IDE – part 1

1 Reply

Easily the most impressive new feature of BricsCAD V18.2 is the new Visual LISP IDE, BLADE (BricsCAD LISP Advanced Development Environment). The lack of any LISP IDE has been a BricsCAD stumbling block for a while, dissuading CAD Managers from adopting BricsCAD to replace their stagnant and increasingly expensive AutoCADs.

As I will relate elsewhere, Bricsys has not just caught up with Autodesk here, but has shot so far ahead it’s unlikely to ever be caught. BricsCAD’s BLADE is so superior to AutoCAD’s VLIDE in so many ways there’s really no comparison.

Yet it remains highly compatible. I have personal experience in making large amounts of AutoCAD LISP code (literally hundreds of routines) work in BricsCAD. That experience tells me that the vast majority of code will work just fine (and much faster) in BricsCAD. A tiny proportion of LISP or DCL code may need adjustment before it will work perfectly on both platforms, and that’s one reason an IDE that works within BricsCAD was an important step that Bricsys needed to take.

I had the chance to see this IDE privately in then-unnamed pre-release form when I attended the Bricsys Conference 2017 in Paris. I was surprised and delighted at the functionality demonstrated by its creator, Torsten Moses. I recently had the chance to interview Torsten about his creation.

Steve: I understand it was difficult to create a LISP IDE for BricsCAD because of the way BricsCAD’s LISP works. Can you explain that?

Torsten: BricsCAD LISP uses the OpenLisp core system, from French developer Christian Jullien. This is the only LISP engine still under development; the others I found stopped development in the mid-90s.

OpenLisp is a very modern implementation, not comparable to the old XLisp dialect used by AutoLISP. Even object-oriented features are supported. Therefore the internal representation of LISP expressions is different from the textual representation as seen in a LISP file.

Steve: So the AutoLISP code I write isn’t the code that BricsCAD executes?

Torsten: That’s right. A number of typical AutoLISP constructions were implemented by a kind of emulation, which drives the internal versus textual representation differences even further. That makes it a major challenge to synchronize the internal OpenLisp expression execution with the related textual representation in order to provide any debugging functionality.

Besides the plain technical details, which seemed to be virtually unresolvable, there was the expected heavy effort to implement a full-blown GUI. This was not just a plain editor, but the entire IDE GUI. It would have been a disaster, a major disgrace, if we had provided a VLIDE that was just up to AutoCAD standards. That was great in its time, but it’s 20 years later now. The idea of creating a LISP IDE for BricsCAD seemed so filled with difficulties that we put it off for a long time.

Steve: How did you finally manage to overcome these difficulties?

Torsten: First, it was a pure coincidence. [laughs] By luck, I discovered a hidden detail in OpenLisp – any LISP symbol (and expressions are a kind of anonymous symbols) can hold unlimited, attached custom data, very similar to XData in DWG database objects. I even knew about that for many years, but never worked out the shortcut to ‘misuse’ this for the LISP expression execution to editor and debugger bidirectional connection. Some initial quick tests showed that this approach was very suitable.

By another coincidence, I discovered that WxWidgets (our cross-platform system, not only for GUI) already includes support for the famous Scintilla editor, an OpenSource editor engine, widely used by many editors. WxWidgets even provides two levels of wrappers – a plain, core wrapper, and a high-level wrapper class system. This fits perfectly into the WxWidgets logic.

But still, that is only plain editor support – not a GUI. Then I found a very suitable, extensible editor and GUI implementation, based on that WxWidgets Scintilla system – as Open Source under the WxWidgets license. Hence, we are allowed to use that source code in a commercial application. That editor is called wxStEdit.

I verified that this source was suitable for our LISP IDE, and put in a lot of extra work to extend it. wxStEdit development finished in around 2008, and it still was compiling and working mostly fine. Nevertheless, in the course of extending that GUI, I found and fixed a lot of defects at all related levels (Scintilla, WxWidgets Scintilla wrapper and wxStEdit).

So it was this set of coincidences that suddenly opened both wings of a big gate!

See here for part 2 of this interview.

This interview is also available in one post on the Bricsys blog.

Bricsys shows Autodesk how to do mid-term updates – again!

5 Replies

BricsCAD V18.2 for Windows is out. The new stuff in this mid-term update is again showing up Autodesk’s lack of progress with its once-flagship product, AutoCAD. I’m sure Autodesk would love customers to accept that there’s only so much anyone can do with a DWG-based CAD product once it reaches a certain level of maturity. Customers should get used to nothing of significance being added year after year. Diminishing returns, and all that. Pay to continue using the product, but don’t expect it to get better.

What a shame for Autodesk, then, that Bricsys exists. By consistently providing a raft of significant improvements with each full and mid-term release, Bricsys shows up that idea as nonsense. It’s perfectly possible to keep improving CAD at a very rapid rate, particularly if you’re not worried about competing with other products in your range. There’s a reason AutoCAD’s parametrics are restricted to 2D, and BricsCAD’s 3D parametrics in a DWG product proves that the reason isn’t technical. It’s strategic. Also strategic is cutting the guts out of an already much-weakened AutoCAD team, because you would really prefer your customers to be using your trendier and/or more expensive products.

I should point out that BricsCAD V18 customers who have a perpetual license, even without maintenance, will be receiving V18.2 with all its improvements free of charge. Contrast that with Autodesk, which is, despicably, withholding even bug fixes from selected customers. Autodesk’s attitude to customers who aren’t constantly paying up front is one of utter contempt. Autodesk feels entitled to your money; Bricsys wants to earn it.

So what’s Bricsys done to earn your money with BricsCAD V18.2?

Mostly, it’s lots of relatively small-sounding things that add up to significant productivity enhancements. There are several items that are playing catch-up to AutoCAD, such as long-overdue in-place text editing. There are big performance improvements in drawings with PDF underlays due to a smart multi-resolution cache mechanism. The 3D-to-2D generation mechanism has also been significantly sped up. Constraints (2D and 3D, unlike AutoCAD) are easier to create. Several 3D direct modeling operations have been made easier. That also helps with sheet metal design, which has seen other improvements.

In Bricsys BIM V18.2, a lot of smarts have been added. The mechanism for converting CAD models (including those made in BricsCAD Shape) to BIM models, BIMIFY, already did some fascinatingly clever things, but that’s been improved further particularly in the areas of structural member and room recognition. For those of us in Australia, support for our steel sections is very welcome.

For me, that’s not the big news. Oh, no. The big news for me is a thing called BLADE – the BricsCAD LISP Advanced Development Environment.

If you’re a CAD Manager or in-house developer and you’ve been waiting until BricsCAD had VLIDE, wait no longer. But this isn’t just catch-up. This is a big leapfrog over Autodesk’s sadly neglected IDE for CAD’s primary user programming language. There’s so much good stuff in BLADE that I can’t hope to do it justice here, so I will be covering it extensively in future posts. For now, here’s a statement for you:

If you program in AutoLISP or Visual LISP, you should be doing it in BLADE.

It’s that good. Really. Watch this space for details.

The download is small, the install is fast, it won’t harm your AutoCAD installation, and you can evaluate it free for 30 days. Links:

BricsCAD V18 – showing Autodesk how to do DWG CAD

4 Replies

For years now, Autodesk has done very little worthwhile with AutoCAD. There have been a few small but welcome improvements, but it’s really just tinkering at the edges. The product as a whole continues to stagnate and yet blimp out. It’s getting bigger and slower with each new release. The downloads get bigger. The install times get longer. The startup times drag out. The responsiveness suffers. And for what? Pretty much the same old thing, every time. Sometimes you don’t even get a new desktop icon. Don’t get me started on value for money.

It’s as if Autodesk considers DWG-based desktop CAD to be a solved problem. Many CAD users accept this. There’s not much more that can be done to improve it, right?

Wrong.

Bricsys has, yet again, proven Autodesk wrong. It is very possible to significantly improve DWG-based CAD. The improvements to the just-released BricsCAD V18 go far beyond anything Autodesk has done for many years, and that’s improving on an already-excellent and innovative product in V17. I’ll be covering some of the most important changes in future posts, but for now here are a few Bricsys links:

BricsCAD V18 release notes. Loooong – just look at all those improvements!
Blog post Announcing BricsCAD V18: faster and smarter!
Blog post BricsCAD V18: The All-in-One Solution for General Design, BIM and Mechanical (posts by the legendary Don Strimbu – failing to hold on to Don was one of Autodesk’s most spectacularly dumb moves).
Video What’s new in BricsCAD V18 (YouTube, 8:42).
Video What’s new in BricsCAD V18 Classic and Pro (YouTube, 2:58) – shorter but not hugely informative.

Don’t take my word for it. The easiest way to test the validity of what I have to say is to try it out for yourself. Unlike Autodesk products, Bricsys downloads and installs are small, fast and efficient. How efficient? This efficient (R.K. McSwain, Twitter):

It’s a 258 MB download for an entire DWG-based CAD application which is significantly more fully-featured than AutoCAD. No nasty malware-like download manager. It’s not a stub or a pre-installer that expands itself before even starting the install proper. It’s a ready-to-run installer for the entire top-of-the-range product capable of parametric 3D, sheet metal design and BIM. It installs and starts up quickly. You can have no trace of BricsCAD on your computer now and be editing your DWGs with it (yes, including your AutoCAD 2018 and Civil 3D DWGs) in a few minutes.

Here’s the download link. You can evaluate it for 30 days.

Did I mention that perpetual licenses are available? Or that it’s way cheaper than AutoCAD? Or that when you report a problem it goes to a real developer who actually cares about fixing it in a reasonable timeframe?

Bricsys 2017 Conference

What’s changed at blog nauseam and why

8 Replies

Last week, blog nauseam died. This post explains the background to that. You’re probably not that interested, so feel free to skip to the dot points that list the changes that have resulted.

The problem was a faulty WordPress installation was using excessive resources. This caused severe performance issues and resulted in the server software stepping in to throttle the site to prevent more widespread problems. The trigger for the WordPress fault has not been determined and may never be. This is somewhat akin to an old AutoCAD drawing suddenly going bad for unknown reasons. The problem may date back years but only recently became critical.

In discussions with my completely blameless web host, Saratoga Hosting, we determined the best course of action was to create a new, clean WordPress site and transfer over as much as possible from the mortally wounded old installation. This is similar to copying and pasting or inserting valid entities from a bad drawing to a clean one, and this is what we did.

I say ‘we’ because Dave from the most excellent Saratoga did a huge amount of work for me to ensure things went as smoothly as possible and with the best result. This is not the first time I have received quite outstanding above-and-beyond customer service from Saratoga in return for the few measly bucks a month I pay for hosting. Thank you, Dave!

Doing things this way provided opportunities for several improvements to both blog nauseam and its parent site, cadnauseam.com. These include:

Improving performance. A clean install that’s not generating many errors per second will load much faster than one that isn’t, just like a small clean program like BricsCAD will perform much better than an old bloated mess like AutoCAD that’s attempting to do hundreds of things a second even when sitting there doing nothing.
Upgrading site security. In addition to various unseen improvements including upgraded protection against hackers and better backups, the site now uses https SSL security, which is the way things are going to have to be in coming years. You may have noticed that the URL now starts with https:// and displays a little closed padlock, indicating this is a secure site.
Integrating cad nauseam with blog nauseam. My old cad nauseam site was a bunch of hand-coded HTML pages that were real cool in the 90s but which have been neglected for years. It’s now part of the same WordPress installation as the blog, which avoids duplication of various things and is much easier to maintain. It also makes sense for me from a business point of view to have my business site more closely associated with a successful blog.
Modern full-screen interface. The integration of cad nauseam and blog nauseam didn’t work well with the old Tempera site template, so I took the opportunity to switch to a cleaner, more modern looking template, Fluida. In addition to being very configurable, this template does all sorts of fancy hover-over stuff that some of you will undoubtedly hate, but in my tests it performed well and didn’t get in my way. The best thing about it is that it’s now full-width: Tempera was not. Some of you won’t like that change either, but I always dislike using a web site that confines itself to a narrow stripe in the middle of a high resolution CAD screen. Now I don’t have to dislike my own site.
I’ve redesigned the favicon to reflect the dual cad nauseam / blog nauseam nature of the site.

I have now restored the polls and image galleries. The automated redirection of old URLs to the new location should now be working. The downloads page is still a work in progress and will remain hidden for a while, but that’s mostly of historical interest anyway.

Again, my apologies for the breakdown and the inconvenience of change, but I’m glad that there have been quite a few positives arising from a bad situation.

If there are things about the site you don’t like now, feel free to let me know.

Link

My apologies for the inconvenience, but please adjust your bookmarks! The home page URL for blog nauseam is now:

https://www.cadnauseam.com/blogs/

The old URL of http://www.blog.cadnauseam.com/ is now permanently inoperative, along with all URLs based on it. The cad nauseam URL of www.cadnauseam.com is unchanged.

The content from the old blog has been carried across and can be found at related URLs. For example, one of the most popular posts is AutoCAD 2017 – Putting things back to “normal”. The URL for this was:

www.blog.cadnauseam.com/2016/07/19/autocad-2017-putting-things-back-to-normal

The new URL is now:

www.cadnauseam.com/2016/07/19/autocad-2017-putting-things-back-to-normal

So all you need to do to is remove “.blog” from the old URL and it will work. I will automate this process if possible but there are complications preventing that in the short term.

Also missing in the short term are polls and image galleries. I’m working on those. If you have any other problems with the site, please let me know by commenting on this post. If you have trouble commenting, please hit me up on Twitter.

I’ll explain some of the other changes around here in a later post.

Props to Bricsys for supporting education

2 Replies

Some time ago I raised a glass to Autodesk for supporting students and educators by making its software available free. I have been remiss in neglecting to point out that Bricsys also does this.

So I raise a glass of dark, tasty and ridiculously strong Belgian beer to Bricsys for doing this. Cheers!

You can still buy Autodesk perpetual licenses in Europe

10 Replies

Yes, you really can still buy Autodesk perpetual licenses in the European Union. You just can’t buy them from Autodesk.

Where can you buy those licenses? From other customers who don’t need them any more. Unlike some jurisdictions, the EU respects the doctrine of first sale for computer software. This means sale of pre-owned software is allowed, and any EULA restrictions attempting to prevent that are invalid. This was established in 2012 by the EU’s highest court, The Court of Justice for the European Union (CJEU) in the case of UsedSoft v Oracle.

Autodesk and all other software vendors in EU countries have to respect that, so the perpetual license remains valid after transfer to the new owner. The previous owner must be able to document the validity of the license and must delete or disable their copy of the software upon transfer.

While I have no personal experience of the transfer process, according to what’s being said in this CGTalk thread*, it’s all very easy. Fill out a form and you’re done. However, I suggest you contact your local Autodesk office for the details. Don’t bother to ask AVA, she doesn’t know.

I’m no EU lawyer, but my reading of the judgement is that Autodesk is not obliged to transfer any maintenance contracts along with the perpetual license (clause 66). It is, however, obliged to consider the software to be upgraded to the original owner’s level under any maintenance arrangements (clause 67). This means the software license will be permanently stuck on the last activated release prior to the sale. Companies with a single license permitting use by 50 users and who want to shed 20 of them can’t split off and sell those 20 (clause 69). Again, check with your local Autodesk office for confirmation.

If you’ve been through this process, please comment on your experiences for the benefit of others.

Software licenses within the EU are valid in all EU countries, so it would appear there is nothing preventing, say, a German buying a used AutoCAD license from the UK, at least until Brexit is complete. It is unlikely that an EU license will be legally valid outside the EU, as outside Europe Autodesk only permits license transfers under certain circumstances described here.

It’s interesting that this market for perpetual licenses exists, but Autodesk has locked itself out of its own market! Indeed, by ending the sale of perpetual licenses, Autodesk has made them a rarer and more valuable commodity.

Bricsys shows Autodesk how to do mid-term updates

2 Replies

BricsCAD V17.2 is out. Although there’s nowhere near as much new and useful in this mid-term update as in the full upgrade from V16 to V17, there’s more here than in Autodesk’s last mid-term update, AutoCAD 17.1. There’s even arguably more than in the uninspired AutoCAD 2018 upgrade, including those 17.1 features.

But that’s not the main reason I say Bricsys is schooling Autodesk in how to do mid-term updates. While Autodesk is restricting such updates (including the bug fixes and security updates included in those updates) to subscription and maintenance customers, Bricsys is doing no such thing.

BricsCAD V17 customers who have a perpetual license, even without maintenance (called All-In by Bricsys), will be receiving V17.2 free of charge. Bricsys still considers such users as customers who have paid good money and still need to be looked after, rather than a non-paying irritant, which appears to be Autodesk’s attitude.

Oh, and you don’t have to install some piece-of-junk automatic updater or malware-like download manager to get the software. You just do a straightforward browser download of a small file (by Autodesk bloatware standards) which is the entire product, and install over the top of your existing installation, effortlessly preserving your settings. If you’re doing a new install of V17.2 from scratch, you just install from that downloaded product. No need for multiple downloads and multiple-step installations. No need to have every PC in your fleet nagging your users and downloading the same huge files.

Autodesk isn’t in the hunt here for ease of maintenance. Not remotely in the same league. Seriously, go home and start again, Autodesk. Your ideas are bad and your execution is worse.

Here are some links to information about the V17.2 update (not neutral sources, obviously):

Bricsys Blog post
Techevate article
Direct modeling update information
BIM update information (BIM is an optional extra but this update is free if you already have it)
Sheet metal update information (another optional extra with a free update)

I will be benchmarking BricsCAD V17.2 and AutoCAD 2018 with great interest. In my preliminary tests, BricsCAD V17.0 performance walked all over AutoCAD 2018 in most areas, but commands involving object selection were the exception, with AutoCAD significantly quicker there. Bricsys is claiming large improvements in that area, but we’ll see.

AutoCAD 2018 – at last, something to praise

1 Reply

This isn’t supposed to be an Autodesk-bashing blog. Really, it’s not. Sure, Autodesk (and anyone else) gets criticism where deserved. There’s been a lot of that lately, but only because Autodesk has thoroughly deserved it. I don’t make up things so I can have a go; Autodesk provides the material all by itself.

Among other things, I’m a customer advocate. I don’t care who you are, act in an anti-customer manner and I’m going to slam you. Hard but fair. Dish up bullshit to your customers and I will gleefully point that out and heap derision on you. Deal with it.

On the other hand, act in a pro-customer manner and I’m going to praise you. I do praise Autodesk (and anyone else) where deserved. There are dozens of examples of that on this blog. Lately, the pickings have been slim. Time to redress the balance a little.

I’ve mentioned before that Autodesk has some great documentation people, including Lee Ambrosius…

…who does a great job with developer documentation. That job’s less visible, but still very important and performed to an excellent standard. Lee is very technically knowledgeable and understands users, developers and their documentation requirements. Within the confines of the systems he’s forced to work with, Lee has done the very best job it would be possible for anyone to do.

Lee has again stepped up to the mark and done exemplary work with the AutoCAD 2018 developer documentation. See Lee’s post for details. This list of AutoLISP changes is an example of the sort of thoughtful addition Lee has provided. Thank you, Lee!

Script for creating AutoCAD Classic workspace